1. Field of the Invention
The present invention relates to information service systems for automatically providing a user with a presenter which is required for viewing desired contents with a viewer regardless of the presence or absence of a user's request and, more specifically, to a storage-based broadcasting system that automatically updates the viewer.
2. Description of the Background Art
Information service systems for providing users with a service for viewing contents require a browser for supplying the content data to a presenter in order to make the content data available to the user. This browser must be appropriately updated depending on factors attributed to the content data to be provided, a transmission channel used for providing the content data to the user, and the presenter on the user's side.
As one example of conventional information service systems, a push-type information distribution service using a computer over the Internet has been realized by, for example, PointCast Network (registered trademark) of PointCast Incorporated, and Active Desktop (registered trademark) of Microsoft Corporation.
In such a push-type information distribution service, contents such as news and weather forecast that are broadcast from a broadcast station over the Internet are received by and stored in a receiver such as a personal computer. A user operates the receiver to activate a browser, which is a user interface for viewing contents. Thus, the user can view the contents stored in the receiver.
Different browsers are used for different services. Consequently, a flexible user interface can be achieved for each service. If the browser needs to be updated, the user receives a new browser by using a function programmed directly on the current browser itself. Then, the current browser is replaced with the received new browser. In this way, the browser can be updated.
With reference to FIGS. 24, 25, 26, 27, 28, 29, and 30, one example of the conventional broadcasting system is now described. As shown in a block diagram of FIG. 24, a broadcasting system 2500 includes a transmitting apparatus 2510, a delivery system 120, and a receiving apparatus 2520. The transmitting apparatus 2510 includes browser storages 2511, browser pitchers 2513, content storages 1113, content pitchers 2514, a multiplexer 115, and a transmitter 116.
There are two or more browser storages 2511, browser pitchers 2513, content storages 1113, and content pitchers 2514 provided. Each of these components is given a symbol with a suffix (lower-case alphabet) added thereto. Hereinafter, the same components are each given the same symbol with a different suffix added thereto for identification.
In the example of FIG. 24, three browser storages 2511 are provided: browser storages 2511a, 2511b, and 2511c; three browser pitchers 2513 are provided: browser pitchers 2513a, 2513b, and 2513c; three content storages 1113 are provided: contents storages 1113a, 1113b, and 1113c; and three content pitchers 2514 are provided: content pitchers 2514a, 2514b, and 2514c. Note that, if each of the same components needs not be specifically identified, they are generally referred to as the browser storages 2511, the browser pitchers 2513, the content storages 1113, and the content pitchers 2514, respectively.
In this specification, if there are a plurality of the same components as described above, they are identified by adding a suffix to each symbol. Furthermore, if each of the plurality of components does not need to be specifically identified, the components are generally referred to without a suffix added to the symbol.
In FIGS. 25, 26, 27 and 28, data stored in the browser storages 2511, the content storages 1113, the storage 133, and the memory 138 in the above broadcasting system 2500 are shown. The three browser storages 2511a, 2511b, and 2511c are independently and respectively provided for three services (S1, S2, and S3). The browser pitchers 2513 each store a browser B that corresponds to a service (S) to be provided to a user, and the browser pitchers 2513 send the browser B to the multiplexer 115 according to a predetermined schedule.
The browser pitcher 2513a for the service S1 stores a browser B(S1). The browser B is a computer program written in native code (machine language) of a CPU (Central Processing Unit) in the receiving apparatus 2520. Similarly, the browser pitcher 2513b for the service S2 stores a browser B(S2), and the browser pitcher 2513c for the service S3 stores a browser B(S3). Note that if each of the browsers does not need to be specifically identified, the browsers are simply referred to as the browser B.
A specific browser transmission technique such as a communication protocol and transmission schedule is defined for each service. Thus, processes carried out by the browser pitchers 2513 vary among the services. For this reason, the browser pitchers 2513a, 2513b, . . . , 2513n (n is an arbitrary natural number) are independently and respectively provided for the services.
In the example shown in FIG. 24, the three browser pitchers 2513a, 2513b, and 2513c are independently provided for the three services S1, S2, and S3, respectively. The content storage 1113 stores a content C of the corresponding service. The content storage 1113 is provided for each service. In FIG. 25, the three content storages 1113a, 1113b, and 1113c are independently provided for the three services, respectively.
In the example shown in FIG. 25, the content storage 1113a for the service S1 stores two service contents C(S1, 1) and C(S1, 2). The content storage 1113b for the service S2 does not store any content C. The content storage 1113c for the service S3 stores three service contents C(S3, 1), C(S3, 2), and C(S3, 3). Note that if each of the contents does not need to be specifically identified, the content is simply referred to as the service content C.
Referring back to FIG. 24, the content pitcher 2514 sends the content C(Sm, O) stored in the content storage 1113 of the corresponding service to the multiplexer 115 in a predetermined manner. In the content C(Sm, O), Sm represents a service S with a suffix m (m is an arbitrary natural number) for identification, and O (O is an arbitrary natural number) represents an ordinal number of a plurality of contents C that form the service Sm.
As such, in the transmitting apparatus 2510 used for the conventional broadcasting system 2500, methods for transmitting browsers and contents vary among services. Therefore, the plurality of browser pitchers 2513 and content pitchers 2514 have to be individually provided for each of the services. Moreover, different transmission methods should be respectively prepared for the browser B and the content C. Therefore, the plurality of pitchers have to be individually provided for the browser B and the content C.
The multiplexer 115 multiplexes and modulates the browser B received from the browser pitcher 2513 and the service content C (Sm, O) received from the content pitcher 2514 to output a digital bit stream. The multiplexer 115 may be structured by a multiplexer and a modulator in a station system for digital broadcasting.
The transmitter 116 receives data processed by the multiplexer 115 and sends the received data to the delivery system 120. The transmitter 116 may be implemented by a modem if the delivery system 120 is structured by a wired communications circuit, or the transmitter 116 may be implemented by a parabolic antenna for transmission if the delivery system 120 is structured by a broadcasting communications satellite in space.
The delivery system 120 is now described. The delivery system 120 is a means for transmitting information, such as contents and browsers sent from the transmitting apparatus 2510, to the receiving apparatus 2520. For example, the delivery system 120 may be structured by an optical fiber or cables of various types, such as a broadcasting communications satellite in space, or a package medium such as a DVD and its distribution channels.
The receiving apparatus 2520 is now described in detail. The receiving apparatus 2520 includes a receiver 131, a de-multiplexer 132, a storage 133, a renderer 134, a presenter 135, an input device 136, a CPU 137, and a memory 138.
The receiver 131 receives information such as the content C and the browser B through the delivery system 120 and outputs a digital bit stream. The receiver 131 may be implemented by a modem, or a module including an antenna and a tuner that are used in general digital broadcasting receivers.
The de-multiplexer 132 demodulates the digital bit stream received from the receiver 131, and separates the multiplexed information. That is, the de-multiplexer 132 carries out the process carried out by the multiplexer 115 of the transmitting apparatus 2510 in the reverse direction. An output from the de-multiplexer 132 is provided to the storage 133 and can be read by the CPU 137.
The storage 133 stores the browsers and contents provided by the de-multiplexer 132. The storage 133 is implemented by, for example, a randomly-accessible recording medium such as a hard disk. Information stored in the storage 133 is readable and changeable by the CPU 137.
As illustrated in FIG. 26, the storage 133 stores the three browsers B(S1), B(S2), and B(S3), and five contents C(S1, 1), C(S1, 2), C(S3, 1), C(S3, 2), and C(S3, 3).
The renderer 134, by following an instruction from the CPU 137, renders graphics for displaying an on-screen display (OSD) on a screen.
The presenter 135 presents an output of the renderer 134 in a form which is viewable by the user. The presenter 135 may be implemented by a CRT display, for example.
The input device 136 is operated by the user to instruct the receiving apparatus 2520. The input device 136 may be implemented by a combination of a remote controller and its photoreceptor, a keyboard, a mouse, or others.
The CPU 137, which is a central processing unit, is interconnected to each component of the receiving apparatus 2520. By executing a computer program stored in the memory 138, the CPU 137 controls the entire receiving apparatus 2520.
The memory 138 is constructed of a writable/unwritable semiconductor memory RAM/ROM. The memory 138 is used for storing data processed by the CPU 137 and for storing a computer program and data to be executed in the CPU 137. As illustrated in FIG. 27, the memory 138 stores a browser list 2700, and a computer program 2651 written in native code (machine language) which is executable by the CPU 137.
With reference to FIG. 28, the browser list 2700 is now described. The browser list 2700 indicates information in a tabular form with rows for the services. The browser list 2700 includes a column 2710 for browser file names and a column 2720 for service names. With the use of the browser list 2700, the browser can be specified for a desired service from among information stored in the storage 133.
With reference to a flow chart in FIG. 29, the main operation of the receiving apparatus 2520 is now described in detail.
In step S2801, all service names (2720) of the browser list 2700 stored in the memory 138 are displayed on the screen in list form. Such screen display is carried out by the renderer 134.
In step S2802, the user operates the input device 136 to select one of the services in the list displayed in step S2801.
In step S2803, for the service selected in step S2802, the file name B(Sm) stored in the storage 133 is obtained by referring to the browser-file-name column in the browser list 2700.
In step S2804, the file B(Sm) specified in step S2803 is executed. The browser is written in native code of the CPU 137, and therefore can be executed directly by the CPU 137.
With reference to a flow chart in FIG. 30, a browser updating process by the receiving apparatus 2520 is now described.
In step S2901, the CPU 137 starts executing the currently-transmitted browser B.
In step S2902, the browser B is received by the receiver 131 and then the de-multiplexer 132, and the version of the browser B is checked.
In step S2903, if the browser B received in step S2902 is a new version of the currently-executed browser B, the procedure goes to a next step S2904, and if not, the procedure ends.
In step S2904, the receiving apparatus 2520 receives the currently-transmitted browser B, and the storage 133 temporarily stores the received browser B as a file.
In step S2905, the currently-executed browser B is replaced with the temporarily-stored file. Then, by rebooting the browser B, the received browser of the new version starts to be executed.
In the above example of the conventional broadcasting system, the browser written in native code of the computer is transmitted by using a method unique to each service. Therefore, various browser transmission methods specific to services have to be incorporated in both transmitting and receiving apparatuses.
That is, in the transmitting apparatus, various browser pitchers specific to services are required. In the receiving apparatus, a function is programmed, typically in the browser code for each service, for receiving a new browser for a new service and replacing the existing browser with the received new browser.
To realize substantially the same function for each service, the browsers each should be implemented in a slightly different specification.
Therefore, as the number of services increases, various needlessness occurs. That is, in the receiving apparatus, a plurality of similar program codes have to be held, thereby wasting the storage capacity. Also, similar processes are simultaneously activated in the receiving apparatus, and therefore computer resources cannot be efficiently used.
Furthermore, browser transmission methods vary among the services, and are programmed only in the browsers. Therefore, the user suffers the inconvenience of manually obtaining the browser in advance by activating a file communications protocol such as ftp.
Still further, there are various differences between the browser and the content in the transmission method. Therefore, in a case where a plurality of services are subscribed, transmission of one service may interfere with transmission of another browser or service.
Also in the transmitting apparatus, slightly different browser pitchers are required for as many as the services in order to achieve browser transmission, which is essentially the same function to any service. Therefore, the transmitting apparatus becomes more linearly complicated in structure as the number of services increases. This complicated structure causes an increase in the development cost and an inconvenience in management.
Furthermore, these browser pitchers have no relation to one another. These browser pitchers may transmit browsers more than the delivery system can handle, thereby causing an overflow. The content pitchers are also independent of one another for each service, and therefore the same problem may occur.